1. Field of the Invention
This invention is directed to providing GDMO (Generic Definition of Managed Objects) name bindings for use in an Opens Systems Interconnection (OSI) system running a Common Management Information Protocol (CMIP) platform. More particularly, the invention relates to building a GDMO naming table for use in a CMIP platform on an OSI system.
2. Description of Prior Art
In OSI management of systems, managed object instances (MOIs), sometimes referred to as instances, managed objects or Just objects, are organized in a relationship tree, called the naming tree. The naming tree represents the naming relationships between MOIs. An instance at a given location in the naming tree is said to be named by its parent in the tree. The naming tree is different from the inheritance hierarchy. A naming tree shows relationships between MOIs, whereas the inheritance hierarchy shows relationships between managed object classes of MOIs. GDMO name binding templates are used to specify the rules which govern managed object instance creation and naming; i.e., the relationships embodied in the naming tree.
Taken together, all of the name binding templates control which MOIs may be named under which other MOIs; i.e., parent-child relationships in the naming tree. Even though the name binding templates govern the naming of MOIs, they control the name in terms of the managed object classes to which each instance belongs. Each naming binding template specifies two classes, with one class being designated as superior, and the other class being designated as subordinate. This superior/subordinate relationship means that an instance of the superior class may be a parent of an instance of the subordinate class in the naming tree.
For example, suppose a name binding template specifies that MOIs of a class "X" are superior to instances of another class "Y" in the naming tree. Then, when an instance of class Y is created, it is created under an instance of class X in the naming tree. Another name binding template may specify Y as subordinate to a third class "Z." In such a situation, when creating an instance of Y, there would be a choice of creating the Y instance under any instance of X or any instance of Z. A generic system which can handle an arbitrary number of classes and name binding templates, and which supports the full range of instantiation alternatives (bringing instances to life) is thus quite complicated.
The problem of creating instances with the proper relationship in the naming tree is significantly complicated further by an option in the OSI standard. This option is the "AND SUBCLASSES" attribute which may be specified in the name binding template. The AND SUBCLASSES attribute may be specified for either the superior or subordinate class of MOIs. If the AND SUBCLASSES attribute is present in the name binding template on the superior class, then instances of the subordinate class may be named under instances of the superior class, or instances of any class which is a subclass of the superior class. Likewise, if the AND SUBCLASSES attribute is present on the subordinate class in a name binding template, then instances of the subordinate class, and instances of any subclass of the subordinate class may be named under instances of the superior class. When AND SUBCLASSES is specified for both the superior and subordinate classes, the set of instantiation combinations permitted grows dramatically. This occurs rather often--systems using the OSI standard, and non-standards, use the AND SUBCLASSES attribute frequently.